Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Restrict system library check to require Java nature #3560

Merged
merged 1 commit into from
Feb 5, 2025
Merged

Restrict system library check to require Java nature #3560

merged 1 commit into from
Feb 5, 2025

Conversation

ptziegler
Copy link
Contributor

The validation of the project classpath introduced with 74d062b always fails, if the project doesn't have a Java nature (and thus usually no .classpath file).

This causes issues when e.g. trying to open a source file with the Java editor or simply when trying to use the AST parser outside of a Java project. With this change, the check becomes more conservative and only fails, if both the Java nature exists and no system library is configured.

Note that one can avoid this exception by disabling the binding resolution. But given that this requires changes in user code, it is more prudent to only fail in cases where this is the desired behavior.

Resolves #3298

Author checklist

@ptziegler ptziegler mentioned this pull request Jan 15, 2025
Closed
@ptziegler ptziegler force-pushed the issue3298 branch 5 times, most recently from b73da0e to 283f9cd Compare January 16, 2025 17:51
@ptziegler
Copy link
Contributor Author

I've added an additional test case that also checks the situation where the AST parser is used without any project.

Note that this currently causes testGH3047() to fail because the source file is parsed without the Java project being set (and also because no requestor is set). This hasn't thrown an exception up until now and therefore, at least from my perspective, shouldn't.

@ptziegler
Copy link
Contributor Author

ptziegler commented Jan 16, 2025 •
edited
Loading

After looking closer testGH3047() and testGH3047_2() are effectively copies of one another, except that the latter is passing the IJavaProject to the ASTParser. The problem is that testGH3047() is effectively the setup we have in our application and what's causing the regression.

@ptziegler
Copy link
Contributor Author

Any chance this can make it into the M3? I've adapted the code to only avoid the exception when opening the Java editor in a non-Java project.

There is still the issue that you can no longer resolve method bindings when parsing Java source code (without a project), which after 74d062b is the now expected behavior.

We have disabled binding resolution for our application. So at least for me, this is no longer a real concern.

@ptziegler
Restrict system library check to require Java nature
3a8673a 
The validation of the project classpath introduced with
74d062b always fails, if the project
doesn't have a Java nature (and thus usually no .classpath file).

This causes issues when e.g. trying to open a source file with the Java
editor or simply when trying to use the AST parser outside of a Java
project. With this change, the check becomes more conservative and only
fails, if both the Java nature exists and no system library is
configured.

Note that one can avoid this exception by disabling the binding
resolution.

Resolves eclipse-jdt#3298
@iloveeclipse iloveeclipse merged commit 8a1b391 into eclipse-jdt:master Feb 5, 2025
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@iloveeclipse iloveeclipse iloveeclipse left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

"Missing System Library" exception in ASTParser
2 participants
@ptziegler @iloveeclipse